Codecov Report

Merging #7100 into master will decrease coverage by 0.28%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7100      +/-   ##
==========================================
- Coverage   85.15%   84.87%   -0.29%     
==========================================
  Files         680      680              
  Lines       38824    38824              
==========================================
- Hits        33061    32952     -109     
- Misses       5763     5872     +109

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fe20ef6...ca05904. Read the comment docs.

Awesome work, congrats on your first merged pull request!

Can you issue a patch version bump? This was merged Jan 8 but I still can't use it :(

How is this still not in 1.10rcs? @potiuk @feluelle

@kaxil -> could we merge this in rc5 as well? This is also a requirement-only change as per rc5 sqlalchemy ? I think it is pretty safe.

On the other hand... If this is only for python 3.8 compatibility, then maybe better to do it in 1.10.11.-> then we could add support to python 3.8 in master and test it in 1.10.11 as well. This is a major version change for cattrs, so there is a risk some obscure problems might occur.

@danieltahara -> we have not yet officially got Python 3.8 compatibility yet not even in master: https://github.com/apache/airflow/blob/master/README.md#master-version-200dev , and there is high chance other things will break with python 3.8 so I think It's better to wait for it until we officially add (and run all tests) for python 3.8. In the meantime 3.6 and 3.7 are also very good choices.

Yes, we don't support Python 3.8 at the moment. Last I check cattrs was still buggy for 1.0.0 & Py3.8

So it will definitely have to wait for next release.

Hi all,

Thanks for the responses. I think I'm finding it confusing that a commit would get merged into master and not used. If it doesn't break 3.6 and 3.7 tests (which it doesn't, since it got merged), and 3.8 is build your own adventure anyway (b/c it's not officially supported), then I don't see the harm in including it in the release.

I understand you have a very specific release branch flow, but the idea a commit can sit for 4 months on master seems like overhead for y'all (cherrypicking, mental overhead of remembering NOT to include the commit) and confusion for the public.

That said, I completely respect that outcome and really appreciate the work you do maintaining the project. Thanks!

Jut to explain - The flow is only because we are now in a process of working on backwards incompatible 2.0 release but in the meantime we release bugfixes and even some features in 1.10 line. It is an overhead indeed but we have to be mindful to our users who want to still have bugs solved and some minor features added and 2.0 version is going to be a bit more difficult to upgrade for them (and it can take months or years because of corporate limitations).

And we do not have to remember of not cherry-picking BTW - we only cherry-pick what we think is worth it. Most of the changes from master branch are not cherry-picked to 1.10.

Surprisingly - it works quite well so far.

To add to what Jarek said, we support Python 2 on Airflow 1.10.* branches, while we don't in Master so, makes cherry-picking process a bit harder for now but provides a good balance between development with new versions will backporting imp features.